The new network architectures are based on the Automatically Switched Optical Network (ASON) defined in ITU-T G.8080/Y.1304 (11/2001), wherein control plane elements (CPEs) are interconnected each other and communicate according to a signalling protocol. Each CPE controls one or more network elements (NE), also defined Transport Plane Elements (TPE), for configuration of the connections starting from the controlled network element (also defined source network element), in order to provide a fast detection of a failure, a fast and efficient configuration of new connections within the Transport Plane, modify the connections previously set up and perform a faster restoration function providing backup connections for protecting connections affected by a failure. Various signalling protocols can fit the ASON architecture, like the Resource Reservation Protocol (RSVP) defined in RFC2205, RFC2209 and RFC2750, the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) defined in RFC3209 and ITU-T G.7713.2, the Label Distribution Protocol (LDP) defined in RFC3036, the Constraint Based-Label Distribution Protocol (CR-LDP) defined in ITU-T G.7713.3 and RFC3472, the Private Network to Network Interface (PNNI) defined in ITU-T G.7713.1.
Referring to RSVP protocol, the base specification was designed to allow network elements (routers) to decide in advance, that is before the provisioning of the connection, if the network can meet the requirements of a Quality of Service (QoS) defined for the connection. The configuration of a new connection is performed transmitting a Path message and receiving, in case of a successful configuration of the connection, a Resv message in the reverse direction of the Path message or receiving a PathErr message in case of an unsuccessful configuration (for example for lack of network resources). Each RSVP message (Path, Resv, PathErr, ResvErr, PathTear, ResvTear, ResvConf) is composed of a common header followed by a body consisting of a variable number (of variable length) of objects. The common header is composed of 8 bytes:
It includes the field “Msg Type” (1 byte) for uniquely identifying the type of message and includes the field “RSVP Length” (2 bytes) for indicating the total length (in bytes) of the corresponding message, including the common header and the variable-length objects that follow. Every object is composed of an header (4 bytes) followed by the object content:
The object header includes the field “Length” (2 bytes) for indicating the total length (in bytes) of the corresponding object and includes the field “Class-Num” (1 byte) for uniquely identifying the object.
The Path message, like every RSVP message, includes the common header followed by the following objects:
<Path message> ::=< common header >  [ <INTEGRITY> ]  <SESSION> <RSVP_HOP>  <TIME_VALUES>  [ <POLICY_DATA> ]  <sender descriptor>wherein the square parenthesis, that is [ ], indicate an optional object. The <SESSION> object includes the IP destination address and the <TIME_VALUES> object includes the value of the refresh period. The <sender descriptor> includes the following objects:
<sender descriptor> ::=  <SENDER_TEMPLATE>  <SENDER_TSPEC>  [ <ADSPEC> ]  [ <RECORD_ROUTE> ]The <SENDER_TEMPLATE> object includes the sender IP address and the <SENDER_TSPEC> object defines the traffic characteristics of the sender's data flow.
The Resv message includes the common header followed by the following objects:
<Resv message>::=< common header >  [ <INTEGRITY> ]  <SESSION> <RSVP_HOP>  <TIME_VALUES>  [ <RESV_CONFIRM> ] [ <SCOPE> ]  [ <POLICY_DATA> ]  <STYLE>  <flow descriptor list>wherein
<flow descriptor list> ::= <FF flow descriptor list> |<SE flow descriptor list>;<FF flow descriptor list> ::= <FLOWSPEC>  <FILTER_SPEC>  <LABEL>  [ <RECORD_ROUTE> ] |  <FF flow descriptor list>> <FF flow descriptor>;<FF flow descriptor> ::= <FLOWSPEC>  <FILTER_SPEC>  <LABEL>  [ <RECORD_ROUTE> ];and wherein<SE flow descriptor list> ::= <FLOWSPEC>  <SE filter spec list >;<SE filter spec list >::= <SE filter spec> | <SE filter spec list>  <SE filter spec>;<SE filter spec>::= <FILTER_SPEC>  <LABEL>  [ <RECORD_ROUTE> ].A number of extensions were added to support provisioning and maintenance of explicitly routed connections (defined LSP=label switched paths). Finally, RSVP-TE allows the aggregation of connections, defined LSP tunnels, which share a common route and a common pool of shared network resources, reducing the amount of information carryed in the network.
The Multi-Protocol Label Switching (indicated with MPLS), which is basically defined in RFC3031(January, 2001) represents an effort in the continued evolution of multi-layer switching, bringing efficiencies in data forwarding, Qos and traffic engineering management. In a traditional connectionless network (for example IP network), every network element (router) runs a layer-3 routing algorithm to determine the path of the data packet through the network; each network element makes an independent forwarding decision, using the information included in the packet header (for example, the destination IP address) and the information obtained from the routing algorithm. This is a slow process, expecially when the forwarding database includes many entries and QoS parameters. On the contrary, in an MPLS network the optimum path through the network is calculated in advance and a label is assigned in front of the data packet; this label accompanies the data packet as it traverses the nework and network elements along the path use this label to determine the next hope network element. Each network element maintains a forwarding database that maps an incoming label/interface with an outgoing label/interface; this switching can be applied to different technologies (IP=Internet Protocol, ATM=Asynchronous Transfer Mode, FR=Frame Relay). The path taken by the labeled packets is called Label Switched Path (LSP). The advantage is that processor-intensive analysis occurs only at the source network element, while the subsequent network elements along the path manipulate this label at hardware level and thus can perform a fast switching, because the forwarding decisions are based on (few) labels rather than on the destination IP address.
Operation, administration and management functions (indicated with OAM) are defined for monitoring traffic carryed over a connection, from a source to a destination network element. OAM functions includes for example:                localization of a fault affecting a connection;        checking integrity of a connection: for example a source network element continually generates a dedicated message and a sink network element continually checks to receive this message;        indication of a fault affecting a segment of a connection to the downstream and upstream network elements of the connection: the downstream indication is usually indicated with Alarm Indication Signal (AIS), while the upstream with Remote Defect Indication (RDI).        
OAM functions are defined for many known protocols, like SDH/SONET, ATM and Ethernet. Specifically, OAM functions for SDH are defined in ITU-T G.806 and ITU-T G.783. The SDH frame includes bytes for performing the OAM functions of the different layers, that is regenerator, section, high-order path and low-order path layers. The SDH frame includes the RSOH including bytes (B1, J0) for monitoring the regenerator layer, the MSOH including bytes (B2, K1, K2) for monitoring the section layer, the high-order POH including bytes (J1, B3, C2, G1, H4, N1) for monitoring the high-order path layer and the low-order POH including bytes (V5, B3, J2, N2) for monitoring the low-order path layer. OAM functions for ATM are defined in ITU-T 1.610. Dedicated OAM cells are defined for monitoring a Virtual Path (VP) or a Virtual Channel (VC), either at segment level or at end-to-end level; each cell includes a type field (fault management, performance management, APS protocol, activation/deactivation) and a corresponding function field (for example AIS/RDI/Continuity Check for fault management). Activation of OAM functions for a VP/VC can be performed according to two different solutions. In the first solution the ATM manager controls directly both the source and the destination network element for activation of the OAM functions according to the following steps:                the VP/VC is previously set up;        the ATM manager sends to the source network element of the corresponding VP/VC a message for indicating activation of a particular OAM function at the source network element, for example the source network element starts to transmit Continuity Check (CC) cells;        the ATM manager sends to the destination network element of the same corresponding VP/VC a message for indicating activation of the OAM function at the destination network element, that is the destination network element starts to check to receive the CC cells.In the second solution the ATM manager controls directly only the source network element for activation of the OAM functions according to the following steps:        the VP/VC is previously set up;        the ATM manager sends to the source network element of the corresponding VP/VC a message for indicating a request of activation of a particular OAM function at the source network element, for example transmission of CC cells;        after receiving the request, the source network element transmits to the destination network element OAM activation cells for indicating a request of activation of the OAM function at the destination network element, that is to check to receive the CC cells;        after receiving the request, the destination network element transmits to the source network element a confirmation to the request;        when the source network element receives the confirmation to the request, the source network element starts to transmit the CC OAM cells to the destination network element.Therefore ATM requires that the VP/VC is previously set up and afterwards the OAM functions are activated. Moreover, the request of activation is sent only to the source and destination network elements and not to the intermediate network elements; this is possible because OAM functions at the intermediate network elements are supported by default, meaning that it is mandatory for a network element compliant to ATM protocol to provide OAM functions and it is only required to activate these functions, through the transmission of a message of activation from the central manager to the source and destination network elements (first solution) or alternatevely through the transmission of a request of activation from the central manager to the source network element and through the transmission of the activation cells from the source to the destination network element crossing the intermediate network elements.        
Link Management Protocol (LMP), defined by Internet draft draft-ietf-ccamp-lmp-10.txt (October, 2003) issued by IETF and updated periodically, specifies a protocol which runs between two adiacent network elements (defined link) and is used to manage TE links, to maintain control channel connectivity, verify the physical connectivity of the data links, correlate the link property information, suppress downstream alarms and localize link failures for protection/restoration purposes. LMP further specifies on paragraph 6.4 that a ChannelStatus message can be used to notify a neighbour that the data link should be actively monitored and that the neighbour must transmit a ChannelStatusAck upon receipt of the ChannelStatus message. Thus LMP can be used only for activation of monitoring of the data link between two adiacent network elements and not for activation of monitoring at all the network elements of a connection, which can include many links.
OAM functions for MPLS are defined in ITU-T Y.1711 (2/2004). Dedicated OAM packets, identified from the user traffic by a reserved value (14) of a label, are defined for monitoring a MPLS path; each MPLS OAM packet includes a function field for indicating Connectivity Verification (CV), Fast Failure Detection (FFD), Forward Defect Indicator (FDI), Backward Defect Indicator (BDI). MPLS OAM packets are transmitted periodically from the source to the destination network element of the LSP. Each MPLS OAM packet further includes in the last two bytes a BIP16 to detect errors of the packet. This standard defines that intermediate network elements transparently forwards the received MPLS OAM packets to the destination network element and defines that a destination network element which does not support the MPLS OAM functionality will drop the received MPLS OAM packets; this has the disadvantage that, in case an intermediate network element supports and activates transmission of MPLS OAM packets, the destination network element (not supporting the MPLS OAM functionality) continually receives and drops the MPLS OAM packets, thus increasing the management traffic. Moreover, this standard defines that processing of a CV or FFD packet should be activated after a LSP is set up, in order to ensure that alarms are correctly enabled.
Therefore OAM functions for MPLS can be supported or not supported by a network element and the problem to check if OAM functions are supported by each network element of a connection arises. This check is also required not only for MPLS, but also for any other protocol, for example in case the network elements of a connection belong to different vendors or to different network domains each one controlled by a different central network manager. In fact in the first case an OAM function could be supported only by network elements of a first vendor and not by a second one, while in the second case each manager can check only if the OAM functions are supported by the network elements of the controlled domain and not by each network element of the entire connection. Referring for example to SDH protocol, the Tandem Connection Monitoring (TCM) function is not supported by default by all vendors, or it is supported according to different solutions; therefore it is required to know if TCM is supported by each network element of the connection or if each network element is compliant to a specified TCM version.
OAM functions for Ethernet are defined schematically in ITU-T Y.1730 (1/2004) and includes:                continuous connectivity check;        fault propagation/alarm suppression functions;        intrusive and non-intrusive loopback;        fault isolation (traceroute);        discovery;        performance monitoring.        survivability functions (e.g., protection switching, restoration).        
Finally, the problem to check if OAM functions are supported by each network element of a connection can be generalized to the problem to check if a generic function is supported by each network element of a connection, like for example:                if each network element is running a specified software release;        if each network element can support performance monitoring functionality and specific performance monitoring functions.        
A straightforward solution to the problem to check if OAM functions are supported by each network element of a connection could be to use a central network manager, controlling all the network elements of the connection. The manager checks if the OAM functions are supported by each network element of the connection by transmitting a first message to each network element of the connection for indicating a request of check if the OAM functions are supported and receiving from each network element a second message for indicating if the OAM functions are supported at the corresponding network element. This solution has the following disadvantages:                it requires a long time because the connection usually includes many network elements and because the bandwidth available for communication between manager and each network element is limited (for example DCC=Data Communications Channels for SDH);        it increases management traffic compared to user data traffic in the network, because the manager must communicate with each network element;        the network elements could belong to different network domains controlled by different network managers and in this case a cooperation between the managers is required for communicating with all network elements of the connection.        
The problem to check if a function is supported by each network element of a connection is not addressed by RSVP, which is a protocol defined expecially for checking if a pre-defined quality of service for a connection is fulfilled and for configuration of this connection.